Skip to main content
Version: V11

Sub Graph Node

The Sub Graph Node executes another workflow as a nested component within the current workflow, enabling modular composition and reusability. It shares workflow state between parent and sub-workflows, allowing sub-workflows to access and modify the same variables as the parent workflow. This modular approach enables complex workflows to be broken into smaller, reusable components that can be maintained independently.

How It Works​

The Sub Graph node enables modular workflow composition by executing another complete workflow as a nested component within your current workflow. When you configure a Sub Graph node, you select an existing active workflow from your workspace, which becomes the sub-workflow. The node loads the selected workflow definition, compiles it into an executable workflow, and runs it with the current workflow state, allowing the sub-workflow to access and modify the same workflow variables as the parent workflow.

When the node executes, it passes the entire current workflow state to the sub-workflow, meaning all workflow variables are accessible within the sub-workflow. The sub-workflow executes its nodes according to its own design, processing data and modifying workflow variables as configured. When the sub-workflow completes, control returns to the parent workflow with the modified state, and execution continues to the next node. Any changes made to workflow variables within the sub-workflow are preserved and available to subsequent nodes in the parent workflow.

The sub-workflow does not require an Output node to return data to the parent workflow. All workflow variable modifications are automatically synchronized through the shared state. To pass specific data to a sub-workflow, set workflow variables in the parent workflow before the Sub Graph node executes—these variables become immediately accessible in the sub-workflow using ${variable_name} syntax. For clarity, consider using a naming convention such as subworkflow_input_ prefix for variables intended as sub-workflow inputs and subworkflow_output_ for variables the sub-workflow produces.

Sub-workflows execute with their own recursion limits to prevent infinite loops when workflows call each other. The node respects the Stream Output Response setting, controlling whether sub-workflow node outputs are streamed to the chatbot interface.

Configuration Parameters​

Sub Graph​

Sub Graph (Dropdown, Required): Searchable dropdown that displays only active workflows available for selection.

The dropdown searches workflows by name, making it easy to find the desired workflow in large workspaces. The selected workflow executes with the current workflow state, accessing all workflow variables from the parent workflow and returning any modifications back to the parent.

The sub-workflow should be designed to work with the workflow variables available at the point where the Sub Graph node executes. Any workflow variables created or modified within the sub-workflow persist after execution and are available to subsequent nodes in the parent workflow. Circular dependencies where workflows call each other recursively can exceed recursion limits and cause execution failures.

Common Parameters​

This node supports common parameters shared across workflow nodes. For detailed information, see Common Parameters.

The Sub Graph node has unique behavior for Stream Output Response: when enabled, outputs from nodes within the sub-workflow are streamed to the chatbot interface according to each node's own Stream Output Response setting. When disabled on the Sub Graph node, all output streaming from the sub-workflow is suppressed regardless of individual node settings.

Best Practices​

  • Design sub-workflows to be self-contained and reusable by avoiding dependencies on specific workflow variable names
  • Document expected input and output variables for each sub-workflow to make integration easier
  • Encapsulate common patterns like data validation, error handling, or multi-step processing into reusable sub-workflows
  • Limit nesting depth to maintain debuggability and performance
  • Test sub-workflows independently before integrating them into parent workflows
  • Use naming conventions like subworkflow_input_ and subworkflow_output_ prefixes for clarity

Limitations​

  • Active Workflows Only: Only workflows with "Active" status can be selected as sub-workflows. Draft or inactive workflows are not available.
  • Shared State: Sub-workflows share the same workflow state as the parent workflow. Changes to workflow variables within the sub-workflow affect the parent workflow.
  • Recursion Limits: Sub-workflows execute with recursion limits to prevent infinite loops. Circular dependencies between workflows can cause recursion errors.
  • No Independent check pointing: Sub-workflows do not maintain separate checkpoints they share the parent workflow's state management.
Did you find this article helpful?